A 10.0 critical severity vulnerablility affecting server-side use of React.js, tracked as CVE-2025-55182 in React.js and CVE-2025-66478 specifically for the Next.js framework.
This vulnerability was responsibly disclosed by myself, Lachlan Davidson on 29 November 2025 PT to the Meta team. Initial disclosure and patch release was performed by React and Vercel on 3 December 2025 PT.
A real public PoC began circulating after around 30 hours from initial disclosure, I've now shared my PoCs several hours later. Full writeup in due course :)
We've seen some great scanners from the likes of Assetnote, which are very effective at detecting unpatched Next.js instances that use Server Components.
However, there's another nuance that we'd like to highlight: The day-0 protections from some providers are actually runtime-level, and not just WAF rules. So many customers with theoretically vulnerable versions are, to our knowledge, still protected.
We're aware of many submissions to Bug Bounty programs, etc. based on these scanner outputs, many of which may be false positives. Unfortuantely, at this point in time, we cannot share any methods to concretely identify with certainity if you are vulnerable. So when in doubt: patch!
We have seen a rapid trend of "Proof of Concepts" spreading which are not genuine PoCs.
Anything that requires the developer to have explicitly exposed dangerous functionality to the client is not a valid PoC. Common examples we've seen in supposed "PoCs" are vm#runInThisContext, child_process#exec, and fs#writeFile.
This would only be exploitable if you had consciously chosen to let clients invoke these, which would be dangerous no matter what. The genuine vulnerability does not have this constraint. In Next.js, the list of server functions is managed for you, and does not contain these.
Many of these "PoCs" have been referenced in publications, and even some vulnerability aggregators. We are concerned that these may lead to false negatives when evaluating if a service is vulnerable, or lead to unpreparedness if or when a genuine PoC surfaces.
Refer to vendor advisories from React and Next.js.
Watch this space. We're giving people time to patch
Thank you to the teams from Meta and Vercel for their work throughout thie disclosure proccess. Their co-ordination with other vendors (such as WAF and infrastructure providers) also provided a meaningful security benefit to vulnerable parties from the very moment the CVE was published.
I'd also like to thank Sylvie Mayer for her initial input when I was exploring the potential of this vulnerability, her collaboration on building early scanners, reconnaissance tools, and alerting affected parties ASAP.
This CVE was (technically correctly) marked as a duplicate of CVE-2025-55182.
The decision to publish a second CVE for Next.js was made due to these exceptional circumstsances: Next.js does not include React as a traditional dependency - instead, they bundle it "vendored". So, if you're using Next.js, many dependency tools do not automatically recognise it as vulnerable.